Arrangement and method for a system for administering certificates

ABSTRACT

A system for administering certificates involves the generation, distribution and recall of certificates for public key systems. The generation comprises generating encryption keys and personalizing smart cards. The system is designed as a distributed system and is divided into a central unit with one or more associated terminal units. Each terminal and center is allocated unique certified identities. Mutual checking of access rights and data contents is carried out between the central unit and each terminal unit. An issued certificate can be traced back to the individual responsible for the issuing, compatibility with standards being seen to exist. Personalization of cards is integrated in each terminal.

BACKGROUND OF THE INVENTION Field of the Invention

The present invention is intended to be used in contexts which willbecome apparent from the preambles of the main claims which areattached.

As a result of developments in telecommunications and datacommunications, an increasing number of sensitive operations are beingperformed without the participating parties being “present” for apossible check on their identity. A consequence of this is that it mustbe possible for individuals and parties participating in an operation tobe identified “electronically”. The methods for doing this up until nowhave, if they have existed at all, been based on the password techniquetaken from the espionage trade. During the last few years, theweaknesses of a password technique as the only method of identificationhave been amply demonstrated by the numerous instances of so-called“hacking”.

A method which establishes more secure identification is that of digitalsignatures, which method can be applied in all the areas where anidentification of the source of an operation or a document needs to beverified. This method simulates the normal manner of identificationwhich is used for transactions outside the electronics field. The methodusing digital signatures is based on the party who is to be identifiedsigning for the transaction (compare ordinary signature on, for example,a contract) and the identity being checked against a comparison originalwhich has the same role as an ID card has for ordinary signatures. Forthis method to be able to function in an electronics context, aninfrastructure needs to be available in order to be able to createelectronic identity documents.

The information which we use to verify an ordinary ID card has (as FIG.1 shows) its equivalent in the electronic identity document. Anotherdefinition for electronic identity document is certificate.

An electronic ID document contains additional information which is of noimportance for this comparison. It is also possible to add otherinformation, in the same way as a given ID card can contain informationspecific to a company.

In order to identify an individual with the aid of an ID document, werequire that the individual concerned will resemble the person in thephotograph and will be able to reproduce the signature. In the case ofcertificates, this is replaced by a technical procedure based oncryptography which uniquely identifies the user.

The confidence we have in an ID document is really a result of theconfidence we have in the organization which issues it, for example acompany or an authority, combined with the fact that the document issufficiently secure in technical terms. As an example of the latter, wecan compare the old driving licences, with a photo stuck on and a stamp,with today's licences which are sealed in plastic.

Just as is the case for issuing an ordinary ID document, the issuing ofelectronic ID documents requires a technical and administrativeinfrastructure.

Crucial to the quality of any ID document is the identification of theindividual which takes place in conjunction with the issuing; this isthe absolutely crucial aspect, the quality of which totally determinesthe quality of the whole document, regardless of whether it is anordinary ID card or a certificate.

This identification is normally done by the person in question beingknown, or by some person or persons, already trusted, vouching for theidentity. It is obviously preferable if this identification can takeplace at as “low” a level as possible, for example departmental level ina company, where, by and large, all individuals are known to each otherand it is easy to determine who belongs to the organization, with whatpowers, and in what capacity.

As far as this part of the administration is concerned, there is nogreat difference between a traditional ID document and a certificate,and in the same way there must be the possibility of verifying that thedocument is still valid etc.

In the case of certificates, the authority which issues and which mayrevoke these is usually called a Certification Authority or CA. Adifference between certificates and ordinary ID documents is that theholder always carries the latter on his or her person, which need not bethe case with certificates; the issuer (CA) also has the role ofpublishing the electronic ID documents (the certificates) in such a waythat these are accessible to anyone requiring access to them. Ifappropriate, information on revoked certificates may be stored togetherwith the certificates.

As regards the CA (Certification Authority), reference is made to ISO9594-8 (The Directory Authentication Framework). In the text whichfollows, we introduce, in the same way as in, for example, PrivacyEnhanced mail (RFC 1114), the restriction that the CA is a clearlydefinable part of an organization.

On the basis of the above, the functions of the CA are defined asfollows:

The CA represents an organization or a clearly definable part of such anorganization in the issuing of certificates. The CA verifies theidentity of the person for whom a certificate is to be created. The CApersonalizes a “token” linked to the identified person. By means ofthis, the CA lets the organization or organization unit guarantee anorganizational identity for the person to which a certificate is issued.

The CA represents an organization or a clearly definable part of such anorganization in the publication of certificates. The CA makes thecertificate known and accessible to anyone, for example through one ormore catalogue services.

The CA represents an organization or a clearly definable part of such anorganization in the revocation of certificates. The CA discloses, in areliable manner, that the organization or the organization unit nolonger vouches for the previously conferred organization identity.

The CA represents an organization or a clearly definable part of such anorganization in the renewal of certificates. The CA extends the validityof the conferred organization identity by issuing a new certificate forthis.

SUMMARY OF THE INVENTION

Since the CA always represents an organization or organization unit, theCA, independently of its internal structure, will be regarded by thosearound it as a unit related to the represented organization ororganization unit.

Since the familiarity with the persons involved in an organization isoften best at the level where the business is conducted, it is alsothere that a person can best be identified, both in terms of thephysical identity of the person and his or her role in the organization.In larger organizations or organization units, no single authority canbe expected to be familiar with the various individuals and their rolesin the way which is necessary to be able to guarantee the organizationidentity of the person.

In consideration of the above, the internal organization of the CA willallow certificates to be issued at the organizational level where theabovementioned familiarity is found.

In the following text it is assumed that the identification procedure isbased on the technique using public keys, and that the “token” which isused is an IC card with built-in computing capacity.

In order to issue a certificate, access is needed to the following:

1. A pair of cipher keys unique to the CA, one public and one private,the private one being used for the digital signature which guaranteesthe identity of the issuer and that the contents of the certificate arenot manipulated. The private key must be stored in such a way thatunauthorized access is not possible in practice.

2. A terminal where the person carrying out the issuing procedure keysin personal data, a certificate is created and signed (this signatureprotects against manipulation of the contents in the certificate). Foreach certificate there is a unique key pair which is linked via thecertificate to the individual.

3. A medium where the certificate holder can safely store his privatekey and carry out the computations necessary during the identificationprocedure. For this, an IC card is used which offers both secure storageof data and reliable use of the private key for computations.

4. Procedures which make it possible for someone requiring access tocertificates to access the latter. This function can be separate fromthe CA both in technical and administrative terms.

The following security risks can be identified:

False certificates. If there are false certificates in circulation, noone can rely on any certificate issued by this CA.

Manipulation of revocation information. Certificates which are no longerto be valid are not included in revocation lists. Completely legitimateoperations will be prevented since the user's certificate will not beaccepted by the other party.

Duplication of information. If several individuals have the sameorganizational identity, no operation or transaction can safely becommitted to one particular individual.

The sources of the above risks can be divided into the followingseparate cases:

An authorized CA operator abuses this trust.

An unauthorized person procures the possibility to operate the CA.

A person succeeds in presenting a false identity at the time when thecertificate is issued.

Functional requirements of the CA:

The certificates are issued in accordance with existing security policy.

Each certificate issued is unique.

Supplied certificates. As regards the storage and supply ofcertificates, it is necessary that the CA be able to place certificatesin the keeping of the authority which is supplying these, for example ina catalogue.

The CA will publish revocation lists.

It will be possible for the certification process to be implemented in adecentralized manner in the organization. This is a precondition forsatisfying the requirement for rapid processing combined with maximumpersonal recognition.

Relation between CAs. Each CA is certified by a higher CA, and each CAcan in turn certify other CAs.

The CA will be able to function in a “multialgorithm environment” wheredifferent certificate structures are used. For example, certificateswith structures for DSS and RSA will be able to co-exist.

The CA functionality will as far as possible be built on generallywide-spread and accepted techniques and standards.

Damage limitation. The CA will be designed and administered in such away that as few valid certificates as possible need to be renewed inorder to eliminate false certificates.

Full authentication of operator. Each operator will be identified by amethod which at least satisfies the requirements for full authenticationas defined in ISO 9594-8.

Complete traceability. When a certificate is issued, it will be possiblefor all the individuals involved, including the operator, to beidentified and traced. All transactions in a CA will be logged securely.

Complete integrity. All information produced by an operator will beprotected in such a way that both intentional and unintentional changesto said information will be detected. Program codes and logs will alsohave protected integrity.

Saved status information. The system will have a sufficiently largeamount of information saved so that issuing of certificates withduplicated information cannot arise.

Physically protected environment. It will not be possible to technicallymanipulate the units involved in such a way that the CA can continue tooperate with its functionality apparently intact.

Confidentiality. Sensitive information will be inaccessible to both theoperator and to outsiders, for example some terminals may need to beprotected against clearing signals.

The invention solves the above set of problems.

SOLUTION

The features which may principally be regarded as characterizing amethod and arrangement which solve the problems mentioned above willbecome apparent from the patent claims attached.

BRIEF DESCRIPTION OF THE DRAWINGS

A presently proposed embodiment of a method and arrangement having thecharacteristics significant to the invention will be describedhereinbelow, reference at the same time being made to the attacheddrawings, in which

FIG. 1 shows a certificate,

FIG. 2 shows the administration of a certificate,

FIG. 3 shows the constructional makeup of the system for administeringcertificates,

FIG. 4 shows the principle of revocation of certificates,

FIG. 5 shows a table of keys and use areas,

FIG. 6 shows another table of private keys and the use areas,

FIG. 7 shows a CA centre,

FIG. 8 shows the basic structure in association with the administrationsystem,

FIG. 9 shows interaction in the system, and

FIG. 10 shows the distribution concept in the system.

DISCUSSION OF THE PREFERRED EMBODIMENT

Starting from the requirements for local verification of the certifiedperson's identity and role and for simple administration, and from thesecurity requirements, the architectural requirements can be summarizedas follows: Distributed function: it will be possible for a certificateto be requisitioned and briefly personalized at the lowest possibleorganizational level, and preferably where this certificate is later tobe used. A basic consideration is that personal recognition is best atlocal level.

The number of security-sensitive parts of the system will be minimized,and the distributed solution will not mean that it becomes moredifficult and/or more expensive to obtain at least the same systemsecurity as with a centralized solution—quite the contrary.

It will be possible for the system to be scaled, and it will also bepossible to adapt it in a simple manner to future organizationalchanges.

The system will be able to administer several different types andcodings of certificates.

The system is assumed to have access to one or more external cataloguesfor distribution of certificates and revocation information. Thefunctioning and interfacing of these are not dealt with at this stage ofthe project.

Components which are only required for initializing the system (forexample, generating initial keys and certificates) are considered uniqueto each system implementation and are not dealt with at this stage ofthe project. Components included are shown in FIG. 3.

The CA central unit represents the central part of the system where CAkeys are stored and where verification and signing of the finishedcertificate take place. A CA central unit will manage to administer oneor more CA terminals. A CA central unit can itself accommodate one ormore CA identities (i.e. one or more private CA keys). A CA central unithas a system-unique identity.

The CA terminal is the unit where an authorized CA administrator makes arequest for a certificate. The CA administrator signs this request andsends it to the central unit. A CA terminal has a system-unique identityand is certified by each CA it serves.

The internal catalogue is used to store system-internal certificateinformation (for example for CA administrators and CA terminals).

The CA administrator is a person with authorization to issue usercertificates at the request of one or more organization units. Eachadministrator has a unique identity, and this is stored in eachcertificate which has been created by the administrator.

The card for the CA administrator contains the identity and, ifappropriate, certificates and signing and authentication keys for theadministrator for which it is issued. Used when the administratorauthenticates himself to the system and for signing certificaterequests.

The card which is to be personalized is the card which the certifieduser receives after keys etc. have been written down in the card. Thecard can be passed on to be presented by the CA administrator.

The different components in the distributed CA have differentroles/functions. Depending on whether private keys are to be generatedin the CA terminal, CA centre, on the administrator's card or on the newuser's card, the roles may vary somewhat.

The tasks of the CA centre are the following:

To authenticate CA terminals. This is done so that the centre will besure that the terminal is one of the terminals which serve the centralunit.

To authenticate CA administrators. Not everyone will be able to act asCA administrator, for which reason authentication is necessary. Thefunction is needed since authentication of the administrator by the CAterminal cannot be checked by the central unit.

To verify certificate data. The CA centre checks the integrity of thecertificate data and checks that it has been-created by an authorizedadministrator by means of verifying the signature of the certificatedata.

To check contents of certificate data. The plausibility of theinformation is checked. The sequence number is compared with previousnumbers, and the period of validity of the certificate request ischecked.

To create certificate contents. The CA centre assembles certificate datafrom CA terminal and CA administrator, and also adds information itself.

To sign certificates. The centre signs the certificate contents usingone of the private keys. Different keys represent different CAidentities.

To create a finished certificate. The CA centre combines the certificatecontents and the signature to form a complete certificate.

Communication with CA terminals. The CA centre communicates with severaldifferent CA terminals. Since it will be possible for this to take placeon completely unprotected lines, the CA centre itself must secure thecommunication. This is done by means of full authentication, sequencenumbers and digital signatures. If the private key is generated in theCA centre, it is necessary to encrypt the communication.

To assemble revocation lists. The CA centre will assemble the revocationmessages from the CA terminals. This is done within a defined timeinterval, for example daily. To send revocation confirmation. The CAcentre will send confirmation, stating that a revocation message hasbeen received and that it was correct, to the CA terminal which sent themessage. If the revocation message was incorrect, the confirmation willindicate what the error was.

To sign revocation lists. For a revocation list to be valid, it must besigned by the CA centre.

To distribute revocation lists. Revocation lists will be distributed tothose requesting them (compare distribution of certificates).

To update the external catalogue. The new certificates will bedistributed to the external catalogue or catalogues.

The tasks of the CA terminal are the following:

To authenticate the CA administrator. Not everyone will be able to actas CA administrator, for which reason authentication is necessary.

To handle data input. The CA administrator will be able to input, in asimple manner, the information which is required in order to create,revoke and update a certificate. This can be done using a “form” whichthe administrator fills in.

To check the plausibility of input information. If the administratorinputs implausible values, the terminal will indicate this and ask for anew value. For security reasons, wrongly input values may need to belogged in some cases.

To create some of the certificate contents. Some information in acertificate is more or less statistical or is given automatically,depending on which administrator is sitting at the terminal. Thisinformation is created by the terminal.

To authenticate the CA centre. This is done so that the terminal will besure that the CA centre is in fact the one expected.

Communication with the CA centre. The CA terminal will communicate withthe CA centre. Since it will be possible for this to take place oncompletely unprotected lines, the CA terminal must itself secure thecommunication. This is done by means of full authentication, sequencenumbers and digital signatures. If the private key is generated in theCA centre, it is necessary to encrypt the communication.

To verify certificates. Before the new certificate is added to the newuser's card, the CA terminal will verify the certificate. In this way itis guaranteed that no change has been made to the certificate en routefrom the centre.

Checking the certificate contents. The terminal checks that theinformation in the certificate agrees with the information expected.

To personalize a card. The CA terminal itself carries out thepersonalization of the user's card. This involves the certificate andthe private key being added to the card, among other things.

To update the external catalogue. The new certificates will bedistributed to the external catalogue or catalogues.

To create revocation messages. The CA terminal will be able to createrevocation messages at the request of the CA administrator.

To handle revocation confirmations. The CA terminal will be able tohandle revocation confirmations from the CA centre. Three cases may bedifferentiated here: the revocation confirmation is given as planned,the confirmation indicates that an error has been made, or theconfirmation is not given.

To open a blocked card. Many cards have functions for blockingthemselves after a certain number of incorrect PIN presentations. The CAterminal will have functions for opening such cards.

To update certificates. The CA terminal will be able to be used toupdate certificates. In order to do this, it is necessary to havefunctions for collecting the certificate which is to be updated,functions for changing information and for adding the new certificate tothe user's card.

The CA administrator carries out:

Data input. The CA administrator is the one who physically inputs theinformation which is required in order to create a new certificate,create a revocation message, unlock a blocked card or update acertificate. Before a new certificate is generated, the administratorwill check the identity of the user and will verify that he/she isindeed to be certified. In the same way, before a revocation theadministrator will check that a user's certificate is indeed to berevoked, etc.

Handles cards. The CA administrator manages the users' cards. Thisinvolves issuing new cards, instructing the users how to use theircards, having a store of non-personalized cards, and so forth. Inaddition, the administrator will make the cards unusable (destroy them)when the stored certificate is revoked.

The user's tasks:

To handle cards. The user is responsible for handling his or her owncard. Among other things, this involves following the rules applying tothe use of PIN codes, and keeping one's card in a safe place.

Information is created, is protected and flows in the distributed CAarchitecture. The components in the architecture interact in ordertogether to create the CA function. The arrangement follows the lifecycle of a certificate—it is created, changed and dies.

The issuing of certificates proceeds as follows: The first thing whichhappens is that the CA terminal authenticates the CA administrator. TheCA administrator then selects the function “Certification of user” onthe CA terminal. If the CA terminal acknowledges the administrator(=successful authentication), a check is made to determine whether thereis a connection with the CA centre. If appropriate, a mutualauthentication and exchange of session key between CA terminal and CAcentre already takes place at this stage. The CA administrator checksthat the user is entitled to certification and verifies the user'sidentity. One of the advantages of the distributed CA architecture isthat this stage is easy to administer in a satisfactory manner asregards security. The CA administrator may be reasonably familiar withthe users he is to certify, since he/she works with them on a dailybasis.

The administrator then uses the CA terminal to complete a form with theuser information and validity periods which are required in order tocreate a certificate. The CA terminal checks the plausibility of theinput information and generates an RSA key pair (keys may optionally begenerated in the CA terminal, in the CA centre, in the administrator'scard or in the user's card). Before certificate data is sent to the CAcentre, the certificate data is signed, together with the service lifeand sequence number of the certificate request, by the administrator(using the administrator's card).

The exchange of information between CA terminal and CA centre isoptionally initiated with one or more authentications. The CA centreverifies the integrity of the transmitted certificate data and checksthe plausibility/accuracy of the information and adds supplementaryinformation to the certificate data. This information consists, interalia, of the user's public key (if the centre generates keys).

The finished certificate is signed by the CA centre and sent back to theCA terminal after the centre has checked that the administrator is stillin position. The terminal verifies the signature and checks theplausibility and accuracy of the information. The administrator, afterchecking the information by sight, will give clearance signals to theterminal to proceed with the personalization of the user's card.

The personalization of cards proceeds as follows: It will be possiblefor a card to be used only when the correct code is presented for it.This code can be left to the user to choose, but this can represent arisk to security since the user likes to choose something associated tohimself/herself. Another alternative is to provide a random code whichis revealed to the user. When the code is available, the card can bepersonalized. This involves, among other things, adding the certificateand the user's private key to the card.

Publication of certificates proceeds as follows: After the certificatehas been successfully generated and the card personalized, the CA centreand/or CA terminal will publish the new certificate at a placeaccessible to those wishing to communicate with the new user, forexample in some form of catalogue. (The characteristics of the cataloguelie outside this part of the project).

It may be necessary to update a certificate if a user changes name ordepartment, if the company changes name, or if the period of validity ofthe certificate is to be extended. The CA administrator selects thefunction “Updating of certificates” on the CA terminal. In practicalterms, the procedure is then the same as for the issuing ofcertificates, with the difference that no keys are generated, the publickey already being present in the old certificate. After a certificatehas been updated, the new certificate must be distributed and the oldone revoked. In addition, the new information must be inserted on theuser's card. It will be possible to update several certificates at atime, this in order to deal with reorganizations and name changes.

A certificate is revoked (=declared invalid) when the certificate hasbecome invalidated for some reason. This can occur, for example, when auser has died, has been found to be unreliable, or his/her role haschanged. Before the CA administrator revokes a user's certificate, acheck will be made according to the administrative rules of theorganization.

Following authentication (in the same way as for the issuing ofcertificates), a signed revocation message is sent to the CA centre. TheCA centre verifies the signature of the CA administrator, checks theplausibility of the revocation message, and sends a confirmation back tothe terminal. The CA centre assembles a revocation list on the basis ofall incoming revocation messages, signs it and distributes the signedlist.

Information required for issuing a complete, signed certificate (of typex.509) comes from:

New user and user's card

CA administrator

CA terminal

CA administrator's card

CA centre

The new user gives his name and any abbreviation to the CAadministrator. This information may already be known to theadministrator, but the user should in any case confirm the accuracy ofthe information. If appropriate, the new user's card may also be used inthe generation of certificate data, namely in the case where the user'scard will generate its own key pair. The public key which will beincluded in the certificate then comes from the user's card.

The CA administrator is the one who, at the CA terminal, physicallyinputs the information required to create a new certificate. Thisinformation is input in a form adapted for the information. Theinformation is:

Name of user, and any abbreviation

Department, possibly automatically by CA terminal

Company, possibly automatically by CA terminal

Country, possibly automatically by CA terminal

Period of validity, starting date and expiry date (if appropriate alsowith clock time)

The CA terminal manages the personal information which is more or lessinvariable, and the key generation:

Department, the CA administrator will be given the possibility ofchanging the department name. One possibility is to let the departmentlast entered be a default value.

Company, the CA administrator will be given the possibility of changingthe company name. One possibility is to let the company last entered bea default value.

Country, the CA administrator will be given the possibility of changingthe country. one possibility is to let the country last entered be adefault value.

The user's public key.

The CA administrator's card provides information on:

which CA administrator has created this certificate.

the user's public key (if the CA administrator's card is responsible forkey generation).

The CA centre indicates:

which CA has certified the user

which algorithm the certificate is signed with

the user's public key (if the CA centre is responsible for keygeneration)

the certificate's signature

The information required for renewing (updating) a certificate comesfrom the same sources as for creating the said certificate. The sametype of form as for creating the certificate can be used, but the CAterminal presents all old values as default values, after which theadministrator changes the fields which are to be updated. These can be,for example, an extended period of validity or the fact that the userhas changed department. However, the user's public key will not bechanged.

The information which is required in order to create a revocationmessage comes only from the CA terminal and the CA administrator. The CAadministrator enters, on an adapted form, information an which user'scertificate is to be revoked. The information required is the user'sname, department, company and country. The CA terminal helps withdefault values.

The CA centre compiles daily a revocation list based on all therevocation messages which have been received during the period.

The issuing of a certificate is shown in FIG. 4a.

The updating of a certificate proceeds in the same way as for creating acertificate, with the difference that the CA terminal collects thecertificate which is to be updated and presents the old information, andthat no keys are generated.

A distributed CA function should not entail any decrease in the securityof the system compared with a CA which is physically implemented in oneplace. A CA located in one and the same place may be easier to makephysically secure, for example it is possible to lock in the CA machineand share out the key to the administrators. Nor is it necessary, in thecentralized case, to worry about communication, particularly via thepublic network.

However, as has already been mentioned, the distributed architecture hasits points. If the communication is secured and the authentication ofparticipating parties is effected in a satisfactory manner, thedistributed CA architecture will instead increase the level of securitybeyond the level which is obtained with the centralized architecture.This is due to the local personal familiarity of the CA administrator,the reduced risk of certification taking place without a satisfactorycheck on the identity of the new user.

CA terminal's authentication of CA administrator. The terminal generatesa random number which is encrypted on the CA administrator's card usingthe private authentication key. The CA administrator's certificate isverified, and the encrypted random number is decrypted with the publicauthentication key in the CA administrator's certificate. If thedecrypted random number agrees with the generated number, authenticationis successful and the CA terminal can be sure that the CA administratoris who he claims to be.

CA terminal's authentication of CA centre. The CA terminal generates arandom number which it encrypts with the CA centre's publicauthentication key and sends to the CA centre. The CA centre decryptsthe random number and sends back the result. The CA terminalauthenticates the CA centre by comparing the returned random number withthe generated number.

CA centre's authentication of CA terminal. The CA centre generates arandom number which is encrypted with the CA terminal's publicauthentication key. The encrypted number is sent to the CA terminal,which decrypts the number with its private key and returns the result.The CA centre authenticates the CA terminal by comparing the returnednumber with the generated number.

CA centre's authentication of CA operator. The CA centre generates arandom number which is encrypted with the CA operator's publicauthentication key. The encrypted number is sent via the CA terminal tothe CA operator's card for encryption. The result is returned to the CAcentre where a comparison is made between the returned number and thegenerated number.

Administrator's card's authentication of CA terminal (and CA centre). Inthe cases where cards cannot communicate directly with the administrator(i.e. the typical case), this is done by means of the card's functionbeing blocked until authentication has taken place. For technicalreasons, this authentication can be limited to, for example, one “key”associated with the administrator's signing key. In this case, theexternal entity is not authenticated individually.

The requirements in respect of communication protection which adistributed CA must satisfy are:

Integrity protection

Authentication of communicating parties

Protection against playback (time stamp and sequence number)

Confidentiality, if key generation in CA centre

A dishonest “genuine” administrator can issue genuine certificates whosecontents do not comply with the organizational rules on issuing. Adishonest “genuine” administrator can recall certificates for falsereasons. It is not possible for just anyone to come forward as anadministrator if a card with associated PIN code is required. Note,however, that from the system point of view it is the card whichconstitutes the administrator. All issuing and recalling of certificateswill be logged in a manner which cannot be influenced by theadministrator who has handled these.

A corrupted administrator card can sign in someone else's name if thestored key is not associated with the administrator who is in charge ofthe card. Anyone can issue certificates if the private signing keystored in the card is revealed. This is avoided by means of secure keygeneration and storage.

A corrupted terminal can make the administrator sign a certificaterequest or a revocation message with contents other than those shown tothe administrator. This is prevented by means of the terminal beingphysically protected against manipulation of software. The terminalshould have as simple a construction as possible and should be withoutthe possibility of program code alteration. The CA centre checks theplausibility of the certificates which are requested to be signed.

If keys are revealed or the program code is manipulated, anyone at allcan issue certificates in the organization's name. CA keys and programcode are stored in a physically secure manner. The CA terminal and theadministrator check the authenticity and plausibility of the data whichthe CA centre returns after signing.

In the event of infiltration into the communication channel, theaccessibility can be destroyed. The communication is cryptographicallysecured. Key exchange takes place in a cryptographically secured manner.

The CA centre will store one or more private keys, each one having itsown specific function. Private keys will be available for signing ofcertificates, revocation lists and logs, authentication, and for keyexchange. If appropriate, one and the same key may be used for severalof these functions.

The private keys which represent different CA identities are used forsigning of certificates (certification) and revocation lists. It will bepossible for different keys to be used for signing of certificates andsigning of revocation lists. The keys may under no circumstances be seenoutside the CA centre and will have strong integrity protection. Thekeys will not be used in any contexts other than at the centre. It willbe possible to remove and add CA identities. In addition, it will bepossible to replace a damaged CA identity with a full copy, and/or givea CA identity a new key pair.

The private authentication key is used when the CA centre authenticatesitself to the CA terminals. The key should under no circumstances beseen outside the centre, and it will have strong integrity protection.It will not be possible for the key to be used in any contexts otherthan at the centre. It will be possible to exchange the authenticationkey.

The private key for authentication of logs should under no circumstancesbe seen outside the centre, and it will have strong integrityprotection. It will not be possible for the key to be used in anycontexts other than at the centre. It will be possible to exchange thekey.

The private key for exchange of session keys should under nocircumstances be seen outside the centre, and it will have strongintegrity protection. It will not be possible for the key to be used inany contexts other than at the centre. It will be possible to exchangethe key. (See FIG. 5).

The CA centre will be able to sign the data. This is done by encryptinga hashing sum of data with one of the centre's private keys. It will bepossible to use different CA identities (different private keys). Itwill be possible to use different hashing functions and encryptionfunctions. Here, great importance is placed on the “correct” data beingsigned and on the correct CA identity being used.

The CA centre will check different input data. This can be, for example,that a certificate request or a revocation message contains plausibleinformation.

The CA centre will log events. The log will be integrity-protected. Itwill be possible to vary in part the matter which is to be logged. Itwill of course be possible for log data to be presented/distributed toauthorized administrators/operators. The following events will be loggedat all times:

when a change is made to what is to be logged

security-related events

initializing data, data on the centre's components, status, etc.

There will be functions which allow an authorized administrator to makea backup of the log and to renew the storage medium.

The CA centre will have an audit function (function for processing logdata). This function will be present at the CA or at another site. Theaudit function will verify that the centre has created the log.

The information which the centre needs to store is:

internal catalogue

logs

revocation messages, and revocation lists

administrator data

information on external catalogues

The CA centre will have support in order to manage several different CAentities. Which entity will be used for signing depends on the role ofthe CA administrator who has sent a certificate request, and possiblyalso on the terminal from which the request originates. The CA centrewill call on the correct CA identity for signing of certificates. Thecommunication will be initiated with a mutual authentication betweenterminal and centre and authentication of administrator. Exchange ofsession key also takes place, if necessary.

On initializing of the CA centre, an internal test will be conducted andany errors logged. Serious errors will result in the CA centre not beingable to be used by CA terminals. Which errors are considered serious isdetermined upon manufacture. On initializing, a check will be made onthe components included in the centre and on their status. The checkresults in information in the log. The log will also include the stageswhich have been carried out in the actual initializing process. It willbe possible for the CA centre to be placed in an environment which isrelatively unprotected in physical terms. This means that the centremust have a strong physical protection, among other things it will beprotected against clearing signals. Unauthorized persons will not beable to “open” the centre and exchange components, alter functions, copyinformation, etc. The administration of the centre which is necessary(see administration) will only be able to be carried out by authorizedpersons. The CA centre will authenticate CA administrators and CAterminals. In addition, the centre will authenticate itself to CAterminals. On request, the CA centre will be able to provide a report onthe status of the components involved, cf. initializing. The CA centrewill be able to verify signatures. The public key which is used forverification will be verified and stored in such a way that it isimpossible to alter. The errors which the CA centre will be able tohandle are: communication errors, security-related errors and internalerrors. When errors occur, these will be logged, if appropriate. Whetherthe errors are to be logged or not depends on the type of error and theparameters which control the logging. Certain errors can mean that theCA centre is “shut down” and stops functioning. An alarm function willbe available which draws the attention of the administrator when errorsoccur. Security-related errors will be logged at all times. The CAcentre will be able to generate keys of different types with variablekey length. The keys which are generated are used to protect thecommunication or are user keys which will be signed. Certificates of CAadministrators and of CA terminals will be stored in an internalcatalogue. The catalogue will have functions for adding, removing andreading certificates. All certificates in the catalogue will have aunique identity. The CA centre will be able to be administered by anauthorized administrator. The administrator must be authenticated beforehe obtains access to the administrator functions. Three different typesof administration may be differentiated: logical, physical, andconfiguration upon manufacture. Logical administration includes:

data base care/maintenance

adding and removing certificates in the internal catalogue

indicating what is to be logged

obtaining a log printout.

The physical administration is what has to be done on the spot by theadministrator:

initiating the centre

adding and removing CA identities

exchanging the centre's private keys for authentication, key exchangeand signing.

When the CA centre is being set up, the algorithms which are to be usedfor line encryption are determined, among other things. A CA centre willbe as simple as possible without compromising security, and thespecification is divided into two parts: base functions, and functionsfor administration and control. The base functions are necessary toensure that the terminal will be able to execute its tasks securely.Other functions do not need to be implemented physically at the centre,but can be dealt with administratively when setting up and configuringthe terminal. The CA terminal will store one or more private keys, eachone having its own specific function. There will be private keys bothfor authentication and for key exchange. If appropriate, one and thesame key can be used for both these functions. The privateauthentication key is used when the CA terminal authenticates itself tothe CA centre. The key should under no circumstances be seen outside theterminal, and it will have strong integrity protection. If there is aspecific key for authentication, this will not be able to be used foranything other than authentication.

Private key for exchange of session keys. The key should under nocircumstances be seen outside the terminal, and it will have strongintegrity protection. If there is a specific key for key exchange, thiswill not be able to be used for anything else.

The CA terminal will support the administrator in the signing of data.This is done by sending data (or a hashing sum of data) to theadministrator's card for encryption with his private key. It will bepossible to use different hashing functions. Here, great importance isplaced on the “correct” data being signed and on the “correct”administrator's card being used. The CA terminal will support theadministrator in the signing of data. This is done by sending data (or ahashing sum of data) to the administrator's card for encryption with hisprivate key. It will be possible to use different hashing functions.Here, great importance is placed on the “correct” data being signed andon the “correct” administrator's card being used. The CA terminal willcheck input data. For example, this can be that the information whichthe administrator gives is plausible and that the signed certificatefrom the centre is correct. The CA terminal will be able to communicatesecurely with the CA centre. This involves protection againstalteration, proof of sender, protection against playback, and in somecases also confidentiality protection. The communication will beinitiated with a mutual authentication between terminal and centre.Exchange of session key also takes place, if necessary.

It will be possible for the CA terminal to be placed in a physicallyunprotected environment. This means that the terminal must have strongphysical protection. Unauthorized persons will not be able to “open” theterminal and exchange components, alter functions, copy information,etc. The terminal will be protected against clearing signals. Thismeans, among other things, that the slot into which the cards areinserted must be protected. The CA terminal will authenticate CAadministrators and the CA centre. In addition, the terminal willauthenticate itself to the CA centre. Each terminal will have a uniquecertified identity and will be able to prove this. The CA terminal willbe able to verify signatures. The public key which is used forverification will be verified or stored in such a way that it isimpossible to alter. The CA terminal will have functions which allow theadministrator to input the data which form the basis of the certificaterequest, revocation message, updating of certificate and “unlocking ofuser card”. The input will be via some type of form. Certain informationin the form is “default” and will be presented by the terminal.

The CA terminal will be able to handle cards and card readers. The CAterminal will report any errors, give instructions and directions to theadministrator. The CA terminal will report any errors, give instructionsand directions to the administrator. The CA terminal will be able togenerate keys of different types with variable key length. The keyswhich are generated are used to protect the communication or are userkeys which will be signed. The errors which the CA terminal will be ableto handle are: communication errors, security-related errors andinternal errors. When errors occur, these will be reported. Certainerrors can mean that the CA terminal is “shut down” and stopsfunctioning. It will be possible for the CA terminal to be configured indifferent ways. The configuration can only be established in conjunctionwith the setting-up and consists of:

configuration of terminal's private keys for authentication and keyexchange

configuration of algorithms for key exchange, encryption ofcommunication, securing of communication, authentication, etc.

terminal's identity introduced (in the form of a private key etc.), eachterminal will have its own certified identity.

On initializing of the CA terminal, an internal test will be conductedand any errors reported. Errors will result in the terminal not beingput into operation. On initializing, a check will be made on thecomponents involved and on their status. The check results ininformation in a report. The report will also include the stages whichhave been carried out in the actual initializing process.

The centre must be set up in a secure environment, and no components orprogram may be corrupt. After the expiry of a CA centre, components canbe reused or destroyed. In addition, the life cycle of the CA centre isdescribed. It is set up, used and dies. Physical and logicaladministration will be possible during the use of the centre, but itwill not be possible for the base components to be altered. After a CAcentre's death, components can be reused or the whole centre can bedestroyed. In order to achieve this (to have a strong protection at thesame time as some administration may be permitted), it is possible tohave the CA consist of two parts. One part which contains the hardwareand the programs (base components) which are needed for the centre to beable to execute its tasks, and one part which makes it possiblephysically to administer the centre during operation. The part with basecomponents is given a physical protection which in principle makes itimpossible to open the part without it being destroyed (becomesunusable). The part with administrative components will be able to be“opened” by an authorized administrator. This division makes it possiblefor an administrator to access the administrative components in thecentre at the same time as the base components are protected. In orderto alter the base components in the protected part, a major operation isrequired which can only be undertaken by the manufacturer.

The protected part with base components represents the core of thecentre. The core has a physically strong protection, and if it isopened, the centre will be made unusable. Only the manufacturer canrestore an opened core so that it functions again. The base componentsconsist of:

communication protocol

logic control

physical control

keys/codes which permit use of the CA centre's private keys

algorithms for key exchange, encryption of communication, securing ofcommunication, authentication, hashing, etc.

This part of the centre can be “opened” by an authorized administrator.In this part there are:

the different CA entities

the centre's private keys for authentication, key exchange and signing.

Since some sensitive components can be removed from the administrativepart, these must interact with the base components in such a way thatthey cannot be used in other contexts. In other words, it will beimpossible to use any of the centre's private keys outside the centre.This means that the base components must “unlock” the administrativecomponents before they can be used. Before administration of theadministrative components is permitted, an authorized administrator musthave authenticated himself to the centre, and if appropriate it is alsopossible to have the administrator or the administrator's card containinformation which is necessary for the centre to be able to beused/initiated.

FIG. 8 describes the various states in which a CA centre finds itselfduring its lifetime. This section summarizes the management undertakenduring the lifetime of a centre: configuration, initiation, logical andphysical administration and physical destruction. The CA centre will beset up in a secure environment with components which are free from errorand inspected (not corrupt); the components do not contain any secretinformation, but they must be integrity-protected. This is a sensitiveperiod in the lifetime of a centre, trust must be complete in thepeople/processes involved in the setting-up. The organization which setsup CA centres should be certified in accordance with certain criteria.

The components which are used should also be certified/inspected. Duringsetting-up, the following base components are introduced:

communication protocol

logic control

physical control.

After setting-up, the centre will be configured. This can be seen as apart of the setting-up and is carried out at the same place, but someinformation in the configuration components is sensitive and will bekept secret.

During configuration, functions, algorithms and data which are lessstatistical in nature are implemented. The aim of this division is to beopen to the developments taking place in the field of encryption. It maybe that algorithms prove weak, key lengths become insufficient, etc.During configuration, the following components are introduced:

keys/codes which permit use of the CA centre's private keys

algorithms for key exchange, encryption of communication, securing ofcommunication, authentication, etc.

The configuration is completed with the base components being given aphysical protection and with initializing and operation being permitted.Initializing will only be able to be carried out by an authorizedperson. During initialization, an internal test is carried out and anyerrors reported. Serious errors will result in the CA centre not beingable to be used. During initialization, a check will be made on thecomponents included in the centre and on their status. The check resultsin information in the log. The log will also include the stages whichhave been carried out in the actual initializing process. Initializingis also carried out after the centre has been physically administered.During initializing, three cases can be differentiated:

a new “Top” CA is initialized, here the CA centre will itself generateits identity

an empty, new CA will acquire an existing identity, this will takeplace, for example, when this CA is certified by another CA at a higherlevel

a CA is restarted after, for example, physical administration, a CAwhich is not empty will not be able to obtain a new identity.

During operation, it will be possible for the CA centre to beadministered by an authorized administrator. The administrator must beauthenticated before he obtains access to the administrator functions.During operation, two types of administration can be carried out:logical and physical. Logical administration includes:

data base care/maintenance adding and removing certificates in theinternal catalogue

indicating what is to be logged

obtaining a log printout

The physical administration is what has to be done on the spot by theadministrator:

initiating the centre

adding and removing CA identities

exchanging the centre's private keys for authentication, key exchangeand signing.

A CA centre dies when someone attempts to access the base components. Adead CA centre cannot be used for anything, except for obtaining thelog. There are two reasons why a CA centre dies: an unauthorized personattempts to access the base components, or an unauthorized person opensthe centre in order to re-configure the centre. The administrativecomponents in a dead CA centre are reused in the new configuration orare destroyed. In order to prevent administrative components in a deadCA centre from being used by an unauthorized person, these componentswill be destroyed. The base components do not need to be destroyed.

Although the distributed CA architecture essentially describes a CAwhich acts freely and independently of other CAs, it is possible in asimple way to make the CA cooperate with other CA domains. This meansthat users are not restricted to their own CA domain. The method ormethods used to communicate between different CA domains can differsomewhat. Either there is a flat CA structure in which each CA in thedifferent domains is its own master, or there is a hierarchy of CAs. Theflat structure has the advantage that all security administration cantake place within one's own domain, independently of a higher authority.No trust needs to be established, no agreements need to be drawn up. Oneis one's own master. The disadvantage of the flat CA structure is thatcross certificates are required (see below) for inter-domaincommunication. As the number of domains increases, the number of crosscertificates will increase exponentially; for a new domain number n+1,two new cross certificates are needed (cf. distribution of symmetricalkeys). The simple key administration which otherwise characterizespublic key systems is destroyed in this way. In addition, creating crosscertificates is an operation which must be carried out safely, otherwiseit represents a risk to security.

In a flat structure, the interaction between different CA domains isobtained with a cross certificate, by means of which the one CAcertifies the other. A cross certificate is in principle the same as auser certificate, with the difference that the public key already existsand will not be generated. In order to obtain a cross certificate, someextra functionality is required in the CA terminal or in the centre.What is important in cross-certification is that the correct public keyis signed. This must be solved by an administrative method, since thepublic key cannot be verified in the normal way. No cross certificatesare needed in a CA hierarchy, since each CA therein is certified by a CAat the level above. The CA at the top certifies itself under strictcontrol. The advantages of a CA hierarchy are that it is simple to breakup certificate chains and that the number of certifications of CAsincreases linearly instead of exponentially. Since the different CAdomains do not certify each other reciprocally, there must be a generalpolicy on how, among other things, certification will take place. Thiscan be seen both as a disadvantage (different domains perhaps have andwish to keep different policies), but also as an advantage, since thereare clear instructions and these are mutual. One problem with a CAhierarchy is the slowness, the checking and the standardizing which arenecessary for introducing such a hierarchy, and it is particularlydifficult to find a suitable authority which is able and willing to actas the TOPCA. In addition, this authority must be accepted by all thedomains involved. It will be possible for the distributed CA to be usedin a CA hierarchy. It can be the TOPCA by virtue of the fact that itgenerates its own identity when initiating takes place with an empty CA,it can be a CA at any other level since initiation with existingidentity is permitted, and it can certify another CA in the same way aswhen certifying users.

KEY TO FIGURES

FIG. 1

1 CERTIFICATE

2 Uppsala County Administration

3 valid from

4 valid to

5 Lena Andersson's public key

6 Digital signature generated by issuer

7 Plastic covering, appearance =recognition

FIG. 2

A. To issue a certificate

1 The person who is to obtain a certificate identifies himself orherself using, for example, an identification card with a photograph.

2 A terminal with card reader is used to introduce the information whichis required in the certificate.

3 A key pair unique to the certificate holder is created and stored inthe terminal.

4 The private key is stored in an IC card completely protected againstaccess and is erased from the terminal. Since encryption can be carriedout in the card, the key need never leave the latter.

5 The public key is stored as part of the certificate, this is open andaccessible to all.

B. Certificate Catalouge

FIG. 3

1 CA central unit

2 One or more CA keys

3 External catalogue

4 Internal catalogue

5 Possible additional CA terminals

6 CA terminal

7 CA administrator

8 Token for CA administrator

9 Token to be personalized

10 User to be certified

FIG. 4

1 CA terminal

2 The CA administrator indicates which certificate is to be revoked

3 . . . and the CA terminal draws up a revocation message

4 . . . which is signed by the CA administrator

5 . . . and sent to the CA centre via the public network.

6 CA centre

7 The CA centre verifies the signature and sends a confirmation to theterminal.

8 The centre periodically creates a revocation list of the revocationmessages . . .

9 . . . signs the list . . .

10 . . . and distributes it to all the authorities concerned.

11 CA terminal

12 The CA terminal presents the confirmation to the administrator. . .

13 . . . who makes the card unusable.

FIG. 4a

1 CA terminal

2 The CA administrator fills in a certificate form...

3 . . . after checking the input information, the terminal generates akey pair . . .

4 . . . and formats the information and public key to certificate data.

5 The certificate data is signed by the CA administrator . . .

6 . . . and sent to the CA centre via the public network.

7 CA centre

8 The CA centre verifies the signature . . .

9 adds supplementary information, formats and signs the certificate . ..

10 . . . and sends the finished certificate back to the CA terminal . ..

11 CA terminal

12 . . . where the card is finally personalized.

13 If the personalization succeeds, the new certificate is distributedto the external catalogue.

FIG. 5

1 Private key

2 The various certification keys which represent CA identity O-N

3 The various revocation keys which represent CA identity O-N

4 Authentication key

5 Log signing

6 Exchange of session keys

7 Area of use

8 Signs user certificate

9 Signs revocation lists

10 Authentication to CA terminals

11 Signing of logs

12 Encryption of session keys

13 Application

14 Certifying new user

15 Compiling revocation lists

16 Communicating with terminals

17 Adding log data to log

18 Initially, when there is a need for subsequent communication to beencrypted.

FIG. 6

1 Private key

2 Authentication key

3 Exchange of session keys

4 Area of use

5 Authentication to the CA centre

6 Encryption of session keys

7 Application

8 Communicating with centre

9 Initially, when there is a need for subseguent information to beencrypted.

FIG. 7

1 CA centre

2 Base components

4 Administrative components

5 Component destruction protection

FIG. 8

1 Set-up, secure environment

2 set-up

3 Hardware configuration

4 Operation, relatively insecure environment

5 Initialization

6 Logic administration

7 Operation

8 Phsysical administration

9 Re-use

10 Death

11 Physical destruction

What is claimed is:
 1. A method of issuing certificates having a uniquedigital signature identifying a certification authority responsible forthe issuing, comprising; providing a distributed system divided into acentral unit and one or more associated terminal unit; providing eachassociated terminal unit and the central unit with unique identities;processing certificates as authorized by a certification authority atone of the associated terminal units or the central unit by mutualchecking of access rights and data contents between the central unit andeach associated terminal unit; and issuing each certificate so that ithas encoded therein access authority for the certificate user designatedalong with a unique digital signature identifying the certificationauthority responsible for issuing the certificate.
 2. A distributedsystem configured to carry out the method according to claim
 1. 3. Thesystem according to claim 2, wherein the certificates each include asmart card.
 4. The system according to claim 2, wherein thecertification authority publishes revocation lists terminatingpreviously issued certificates and wherein the certification authorityis made up of different certificate issuers, each certificate issuerhaving a unique digital signature and being certified by a higherranking authority and each certificate issuer being able to certifyother lower ranking certificate issuers.
 5. The system according toclaim 2, wherein the certification authority is configured to functionin a multialgorithm enviornment in which different certificateencryption algorithms can be used.
 6. The system according to claim 2,wherein the associated terminal unit or the central unit including thecertification authority further includes means for logging alltransactions involved in issuing the certificate and means for uniquelyidentifying each operator and encoding unique operator identify intoeach issued certificate so as to make it possible to identify and traceall operators involved in all the transactions.
 7. The system accordingto claim 6, further including means for detecting all informationproduced by an operator and for protecting the information fromintentional and unintentional changing and means for protecting programcodes and logs.
 8. The system according to claim 2, comprising a storagedevice configured to hold a sufficiently great amount of storedinformation so that issuing of certificates with duplicated informationcannot arise and means keeping sensitive information inaccessible to anyoperator and any outsiders.
 9. The system according to claim 2, whereinthe system is scalable and adaptable to future organization changes andthe system includes means for handling several different types of codesand certificates.
 10. The system according to claim 2, wherein there areone or more external catalogues for distribution of certificates andrevocation information for terminating certificates and furtherincluding means for initializing the system by generating initial keysand means for ensuring that issued certificates are unique to eachsystem configuration.
 11. The system according to claim 2, wherein thecentral unit includes the certification authority provided as one ormore certification authority administrator terminals having private keysproviding a system-unique certification authority administrator terminalidentity as the unique digital signature.
 12. The system according toclaim 2, wherein each associated terminal unit includes a certificationauthority administrator acting as the certification authority with asystem-unique identity functioning as the unique digital signature. 13.The system according to claim 2, further including an internal catalogueconfigured to store system-internal certificate information relative tocertification authority administrators acting as the certificationauthority issuing certificates at the request of one or moreorganization units, where each certification authority administrator hasa unique identity and this is stored in each certificate which iscreated by the certification authority administrator as the uniquedigital signature.
 14. The system according to claim 13, wherein eachcertificate is delivered to an authorized user by the certificationauthority administrator.
 15. The system according to claim 2, whereinthe central unit includes means for ensuring that any terminal unitcommunicating with the central unit is an associated terminal unit whichis authorized to communicate with the central unit, means forauthenticating one of a group of certification authority administratorsas the certification authority for issuing each certificate, means forverifying certificate data, means for checking integrity of certificatedata and that the certificate data has been created by an authorizedcertification authority administrator, means for checking contents andplausibility of the certificate data, means for comparing a sequencecertificate number with previous certificate numbers, means for checkinga period of validity for the certificate request, means for compilingcertificate data from the associated terminal unit, the certificationauthority administrator, and information added by the central unit toissue a certificate, where the central unit communicates with differentassociated terminal units on completely unprotected lines, the centralunit having means for providing secure communications on saidunprotected lines.
 16. The system according to claim 2, wherein eachassociated terminal unit includes means for authenticating acertification authority administrator as the certification authority,means for handling input data, means for checking the plausibility ofthe input data, means for creating part of the certificate contents,means for authenticating the central unit, means for communicating withthe central unit, means for verifying certificates, means for checkingthe certificate contents, means for personalizing the certificates forindividual users, means for updating external catalogues, means forcreating revocation messages to terminate issued certificates, means forhandling revocation confirmations, means for opening any blockedcertificate, and means for updating certificates.
 17. The systemaccording to claim 2, wherein the certification authority includes anadministrator and is configured to provide physical input of datarequired to issue a certificate, to create a revocation message, tounlock a blocked certificate, to update a certificate, and to makecertificates unusable when the certificate is revoked.
 18. The systemaccording claim 2, wherein the certificates include PIN codes.
 19. Thesystem according to claim 3, wherein the certificate authority publishesrevocation lists terminating previously issued certificates and whereinthe certificate authority is made up of different certificate issuers,each certificate issuer having a different unique digital signature andbeing certified by a higher ranking authority and each certificateissuer being able to certify other lower ranking certificate issuers.20. The system according to claim 3 wherein the certification authorityis configured to function in a multialgorithm environment in whichdifferent certificate encryption algorithms can be used.